Public: Concord Software Projects : Capistrano ssh and git

This page last changed on Mar 25, 2009 by stepheneb.

Work in progress (more details about cap recipes and git settings should be filled in)

SSH Config params:

Capistrano will look at your .ssh/config settings by default when deploying to a remote host. It will try to find the first host entry which matches your deploy host. For that reason, you want to set your remote username in your .ssh/config file. If no user is specified it will attempt to use what ever is set as $USER on the host you are running cap from.

Here is an excerpt from my config file:

~/.ssh/config

Host *.concord.org
  User npaessel
  ForwardAgent yes
Host *
  ForwardAgent no

(The ForwardAgent lines are irrelevant for this discussion, but are nice to have around)

A copy of your public key should exist in .ssh/authorized_keys on the deploy host. See http://confluence.concord.org/display/TSC/Automatic+ssh-agent+startup+for+shell+users for more info on that.

If you are not running a ssh agent, you will be asked for the keys passphrase once.

sample cap deploy

 
bash-3.2$ cap deploy
    triggering start callbacks for `deploy'
  * executing `multistage:ensure'
*** Defaulting to `staging'
  * executing `staging'
  * executing `deploy'
  * executing `deploy:update'
 ** transaction: start
  * executing `deploy:update_code'
    updating the cached checkout on all servers
    executing locally: "git ls-remote git://github.com/stepheneb/rigse.git master"
  * executing "if [ -d /web/rites.concord.org/shared/cached-copy ]; then cd /web/rites.concord.org/shared/cached-copy && git fetch  origin && git reset  --hard ee6b6eb5fce8a03c155e3b23f9392bcdf46f5eb6; else git clone  git://github.com/stepheneb/rigse.git /web/rites.concord.org/shared/cached-copy && cd /web/rites.concord.org/shared/cached-copy && git checkout  -b deploy ee6b6eb5fce8a03c155e3b23f9392bcdf46f5eb6; fi"
    servers: ["rites.dev.concord.org"]
Enter passphrase for /Users/npaessel/.ssh/id_dsa: 

(etc)

Stephen's path to the same result ...

I though it might be interesting to describe the path I took to get to the same answer.

I had this in ~/.ssh/config:

Protocol 2,1
ForwardX11 yes
# User sbannasch                                                                                                                                                                                                                  
User sbannasch

That along with a public key setup allows me to login to all the *.concord.org servers.

NetSSH can login using my public key:

$ ruby -e 'require "rubygems"; require "net/ssh"; Net::SSH.start("otto.concord.org", "sbannasch") { |ssh| puts ssh.exec!("pwd") }'
/home/sbannasch

But Capistrano which uses the Ruby Gem NetSSH didn't work.

I opened the code for the Capistrano and NetSSH gems in my editor and found the code in question by searching for ".ssh', 'user', and 'config'.

Here's the real clues starting at line 43 in file: /Library/Ruby/Gems/1.8/gems/net-ssh-2.0.11/lib/net/ssh/config.rb

# Loads the configuration data for the given +host+ from all of the
# given +files+ (defaulting to the list of files returned by
# #default_files), translates the resulting hash into the options
# recognized by Net::SSH, and returns them.
def for(host, files=default_files)
  translate(files.inject({}) { |settings, file| load(file, host, settings) })
end

And running this in Ruby IRB:

require 'net/ssh'
Net::SSH::Config.for('otto.concord.org')

returned an empty hash

{}

This ssh man page was helpful:

http://www.eos.ncsu.edu/remoteaccess/man/ssh.html

Adding a *.concord.org Host value before the User parameter in ~/.ssh/config allows the Ruby Net::SSH gem to find the sbannasch username:

Protocol 2,1
ForwardX11 yes
# User sbannasch                                                                                                                                                                                                                  
Host *.concord.org
User sbannasch

Now the result in Ruby is:

{:user=>"sbannasch"}

And cap deploy now connects to the server correctly.

Document generated by Confluence on Jan 27, 2014 16:52